MorphIT Layouting

This page describes how the current layouting mechanism of the MorphIT web interface works. The goal of MorphIT was to create a web interface in which most native applications run without further customization. However, this is not always possible due to the differences between native interface and web interface. To write applications that look good both natively and on the web it is necessary to understand the additional rules and restrictions that apply to the web interface.

Concept: Window

The current MorphIT web interface always shows the active window as web interface. Since several windows are rather annoying in contrast to native web interfaces and cannot be used effectively on small devices, MorphIT only shows the active window as web interface. The goal of a good ClassiX application should therefore be to be able to edit a use case via one window without switching to other windows. If several windows are open in ClassiX, only the currently active window is displayed. The user will not notice any background windows.

In order to offer the user a selection dialogue without changing the whole window, MorphIT supports modal windows and float windows. These are drawn as moveable and closable windows above the current surface.

Concept: Toplevel Groups/Composites

In the following text groups and composites are used synonymously.
The main difference between native interface and web interface is the available size.

Native user interfaces are defined for windows that are usually laid out for desktop applications and can adapt their content via attachments and resizing of the window. The windows are usually designed so that all information fits on the desktop. Scrolling of windows is rather unusual in native interfaces. The font (if not configured differently) is based on the font size for interface elements commonly used in Windows.

A web interface must be easy to use on a desktop as well as on a tablet or smartphone. To make this possible, larger fonts are used and interface containers are adapted to the available width and, if necessary, displayed one below the other (see: Responsive Design). A core conflict between native interface and web interface is the height of the interface. Native it is given by the window height and the elements have to adapt to the available height and on the web the elements in their sum should determine the total height of a window.

Group width

The responsiveness of the web layout is supported by the fact that all top-level groups are interpreted as responsive containers which occupy a defined number of columns in a 6-column grid depending on the ratio between the width of the group (in the InstantView source code) and the width of the contained window (in the InstantView source code). A toplevel group can thus occupy the widths 16%, 33%, 50%, 66%, 83% and 100% of the total window width. When calculating the width, attachments of the toplevel group to the parent window are taken into account, so that the group from the following code example will take up the entire window despite a width of 0 due to the attachments:

Window(window, 0, 0, 350, 100, "Parent Window") 
{
  Group(group, 0, 0, 0, 0, "The group") 
  Attach(group, LEFT, RIGHT, STRETCH)
}

If the browser is dragged smaller, the number of columns per group increases, so that at some point even the smallest groups take up the entire window width and the groups wrap around and are displayed one below the other.

Important: The example shows another point that needs to be considered. The window is with 350 minicells (~245 pixels) natively quite narrow and the group would be natively only 245 pixels narrow, which looks very small on a 1920 pixel wide screen. For the group width in MorphIT, however, only the ratio between window size and group size counts, so that in this case the group receives 100% of the available window width and would therefore be displayed in MorphIT on a full screen about 1200 pixels wide. Such a small group, stretched to such a size by attachments, can look somewhat unnatural and be difficult to layout.
In web layout, for very large screens, about 1270 pixels are available for the window width. In order for the groups to match the native group widths in the window in absolute sizes, the 1815 Minicells window would have to be chosen wide.

Toplevel groups are all groups and composites that are either contained directly (without enclosing group) in a window or in a notebook window, which in turn is contained directly in a window. Whether MorphIT has recognized a group as toplevel can be checked in the browser by examining the group element and checking whether the CSS class toplevel was assigned to the element.
By using the columns for the Responsive Design on the Web, top-level groups ignore the positional indications in the InstantView code, which conceptually contradict a fixed positioning and a Responsive Design at the position. The order of the groups results from the order in which the groups were defined in InstnatView.

This is illustrated by the following example:

Window(Layout2, 0,0, 800, 300, "Layout 2")
{
    Group(g1, TOGGLE, 400, 0, 400, 100, "400,0,400,100")
    {
        Group(g11, 0, 10, 200, 90, "0,20,200,100")
        Group(g12, 200, 10, 200, 90, "200,20,200,100")
    }

    // g2 is placed before g1 using absolute coordinates (this is ignored in web)
    Group(g2, TOGGLE, 0, 0, 400, 200, "0,0,400,200")
    {
        Group(g21, 0, 10, 400, 90, "0,10,400,90")
        Group(g22, 0, 100, 400, 90, "0,100,400,90")
    }
}

The TOGGLE flag is used to make the group collapsible on the web, so that the user can reduce a long interface to the necessary elements by collapsing the elements of groups. This state can also be controlled by the InstantView developer via the MorphIT slot isHidden.

Native Layout

Web-Layout (large)

Web-Layout (small)

Web-Layout (small & folded)

In the examples, the top level groups are coloured green and the sublevel groups blue. The examples also show the next limitation of the web interface. The used font size of the group headings is almost twice as big as the usual native group heading. This font size is predetermined by the design and serves for better orientation on the web interface and thus for usability. In addition, the group must leave space for the TOGGLE button, which does not exist natively.
Group spacing and sizes should natively be chosen slightly larger than absolutely necessary so that the web layouts remain usable.

A similar font size for group headings could be set using the following code:

3 [ 17 ] MSFonts

This makes it easy to see whether a mask is designed for large group headings or not. Currently, setting the larger group heading is not a solution for the layout mismatch between native and MorphIT, because the groups calculate the Y-position for their sub-widgets differently.

Group height

The group height of a toplevel group results directly from the InstantView source code. Vertical attachments of the group to the window above are also taken into account for the group height. Vertical attachments of the toplevel groups to each other are only considered for the initial size. Since the web interface can scroll vertically as far as desired, the height of the browser window does not influence a group that is dynamic in height by means of a stretch attachment in any way. The only exceptions to this are modal and float windows, as they have an (initially) limited height.

Top level groups with headers and dynamic height (STRETCH) in modal and float windows lead to layout problems in the current MorphIT version, which will only be solved by the next positioning engine.

Dynamic group height

Since it is common in the web that the content determines the height of the entire window and lists are scrolled over the window rather than having a separate scroll bar for each list in the window, MorphIT has included the possibility for list widgets(ObjectListView & TreeList) as well as for WebWidgets to resize these widgets to fit their content. For this to work, the widget itself and all parent groups up to the toplevel group must be vertically-stretch-attached to the respective parent. The toplevel group does not need to be stretch attached. If this condition is met, the widget adjusts the height of the toplevel group so that the entire content can be reached without scrolling. If the condition is not met, then a scroll bar is displayed in the list widget as natively.
The list height from the source code indicates the minimum height of the list. An empty list will never shrink below this height.

The behaviour is illustrated in the following example:

Window(Layout3, 0,0, 600, 100, "Layout 3")
{
    Menu
    {
      Item("Fill lists")
      [ SELECT: FillLists ]
    }

    // Group and list stretch attached to bottom
    Group(g1, 0, 0, 200, 100, "bottom stretch list")
    {
      ObjectListView(list1, AUTO_POSITION, 0,10,0,0)
      [INITIALIZE: PrepareList ]
      Attach(list1, LEFT, RIGHT, BOTTOM, STRETCH)
    }

    // Only group stretch attached to bottom
    Group(g2, 200, 0, 200, 100, "no stretch list")
    {
      ObjectListView(list2, AUTO_POSITION, 0,10, 0, 90)
      [INITIALIZE: PrepareList ]
      Attach(list2, LEFT, RIGHT, STRETCH)
    }

    // Only List stretch attached to bottom
    Group(g3, 400, 0, 200, 100, "no stretch group")
    {
      ObjectListView(list3, AUTO_POSITION, 0,10,0,0)
      [INITIALIZE: PrepareList ]
      Attach(list3, LEFT, RIGHT, BOTTOM, STRETCH)
    }

    Attach(g1, BOTTOM, STRETCH)
    Attach(g2, BOTTOM, STRETCH)
}

Without data

empty lists native

Empty lists on the web (large)

Empty lists on the web (small)

With data

Filled lists native

Filled lists on the web (large)

Filled lists on the web (small)

Here too, the toplevel groups are coloured green for better understanding.

A special position of the dynamic group height is taken by the rich text editor. It does not adjust its height to the content, but only to the size set by the user - the editor can be enlarged at the lower right corner with the mouse.

Layouting of Childwidgets

Within toplevel groups, however, the absolute positioning applies again, for which the (X,Y,width,height) specification of the widgets is converted into pixels and displayed in the browser. The attachment layout also works here, but the LAYOUT flag is not supported!

The group heading is part of the specified group height of sublevel groups. This means that the larger group heading on the web takes up more space in the group content compared to the native interface. This must be taken into account when positioning sublevel groups so that they do not overlap. For top level groups the height of the group heading does not count towards the group height.

The position of the widgets within the groups is converted from the native interface to the web interface in such a way that, as far as possible, the group content matches the native group content with pixel accuracy. If the group becomes smaller by reducing the size of the browser, the size/positions of the contained widgets will of course also adapt to the new, available size.

Layout of notebooks

For notebooks there are some special rules for layouting, as they are often used to display several windows in a single window. This is especially useful in MorphIT, which only shows one window at a time, and is a tool to structure complex surfaces.

Notebooks take up the entire size of their container natively without specifying coordinates, as well as on the web, i.e. they fill the entire window or the group it contains.

If the size and position of notebooks is specified, it is natively taken into account, but is completely ignored in MorphIT. Notebooks always fill the entire width of the containing window (or group) and if there are several notebooks in one window, the notebooks are displayed one below the other. Since notebooks can contain different sized contents, the height of the notebooks is determined by the height of the contents of the currently active notebook tab. If the notebook is in a group that restricts the height of the notebook, the contents can be scrolled using a scroll bar that is displayed.

Groups within notebooks

If groups are placed in a notebook that is directly in a window, then these groups are also treated as toplevel groups and thus adapt to the size of the window, break up and can adapt in height to the content. Conversely, however, this also means that the position of the groups within a notebook is normally ignored. This also applies to nested notebooks as long as no notebook is included in a group. In the following example code the group group is contained in a notebook, which in turn is contained in a notebook. Since none of the notebooks is contained in a group, the group is still laid out as a toplevel group.

Window(Layout2, 0,0, 800, 300, "Layout 2")
{
  Notebook
  {
    Window(win1, 0, 0, 0, 0, "outer")
    {
      Notebook
      {
        Window(win2, 0,0,0,0,"inner")
        {
           Group(group, 0,0,800,300, "toplevel group")
           {
             Button(bt1, 10, 10, 200, 10, "some button")
           }
        }
      }
    }
  }
}

If a group is located in a notebook, which in turn is located within a group, then the group is no longer laid out as a toplevel group and its position and size are correctly taken into account.
Example:

Code	Result
Window(Layout2, 0,0, 800, 200, "Layout 2") {   Group(top, 0, 0, 800, 200, "toplevel")   {   Notebook   {   Window(win1, 0,0,0,0, "page")   {   Group(sub, 400, 50, 400, 100, "sublevel")   {   Button(bt1, 10, 10, 200, 10, "some button")   } } } } }	A group in a notebook in a group Here too, top-level groups are recommended for better Understanding coloured green and sublevel groups blue.

A notebook is treated by the layout mechanism as a vertical stretchattach group, so that in the following layout:

• Group
  • Notebook
    • Window (Tab)
      • Group
        • List

the height of the list can be adjusted to the number of elements to be displayed, if the inner group stretched vertically to the contained window.

Other special features

Password fields

Strings with the PASSWORD flag are also displayed as password fields in MorphIT, but within the widget they receive a small icon (25px wide) with which the accessibility password can be displayed in plain text. This means that a password field should also be selected natively sufficiently wide so that the lack of space does not impair the use of the field.

Date fields

Date widgets automatically receive a date picker in MorphIT. This date picker is about 30 pixels wide and is subtracted from the width of the input field of the date widget. In order for a date widget to be usable in MorphIT, it should not be large enough to enter a date, but a little wider.

Multilingual texts

In MorphIt, the first line of the MLText widget consists only of the language selection. So if an MLText widget is natively adjusted to one line in height, the height of the widget in MorphIT will not be sufficient. For single-line, multilingual input, either MLString should be used or the height of the MLText widget should be slightly larger.

Rich text editor

If a text widget is displayed as a rich text editor via the MorphIT slot morphIt.description, it must be taken into account here that the editor contains a toolbar that reduces the editable area vertically by about 45 pixels and the corresponding text widget should be selected sufficiently high.

Summary of restrictions

1. The LAYOUT flag is not supported.
2. The position specification of toplevel groups is ignored.
3. The width of toplevel groups is relative to the window width and not absolute.
4. Group headings are much larger for the web and the group must be set higher/wider than would be necessary natively.
5. Vertical STRETCH-attach is only used to determine the initial size for toplevel groups. Enlarging the browser window does not change the height of such groups.
6. The position and size of notebooks is not taken into account.
7. Password fields and date fields should be a little wider on the web.
8. MLText and Richtext should be chosen slightly higher on the web.
9. Modal and float windows should not have attached toplevel groups with headings.

Visualise layout

To find layout errors easily and quickly, the following browser bookmarklet can be used as a bookmark, which activates the style used here. This gives all groups a frame and top level groups are marked green and sublevel groups blue.

javascript:(function(){
  if (document.getElementById('debug-style')) {
    document.getElementById('debug-style').remove();
  } else {
    var style=document.createElement('style'); 
    style.id='debug-style';
    style.innerHTML=".toplevel.GROUP,.toplevel.COMPOSITE,.toplevel.GROUP:last-of-type,.toplevel.COMPOSITE.last-of-type{border:1px solid black;background-color:rgba(0,255,0,0.2)}.sublevel.GROUP,.sublevel.COMPOSITE{border:1px solid black;background-color:rgba(0,0,255,0.2)}.GROUP>.GroupContentWrapper,.COMPOSITE>.GroupContentWrapper{background-color:transparent}";
    document.head.appendChild(style);
  }
})();